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ABSTRACT 

Dereferencing a URI returns a representation of the current 
state of the resource identified by that URI. But, on the 

Web representations of prior states of a resource arc also 
available, for example, as resource versions in Content Man- 
agement Systems or archival resources in Web Archives such 
as the Internet Archive. This paper introduces a resource 
versioning mechanism that is fully based on HTTP and uses 
datctimc as a global version indicator. The approach allows 
"follow your nose" style navigation both from the current 
time-generic resource to associated time-specific version re- 
sources as well as among version resources. The proposed 
versioning mechanism is congruent with the Architecture of 
the World Wide Web, and is based on the Memento frame- 
work that extends HTTP with transparent content negoti- 
ation in the datctimc dimension. The paper shows how the 
versioning approach applies to Linked Data, and by means 
of a demonstrator built for DBpedia, it also illustrates how it 
can be used to conduct a time-series analysis across versions 
of Linked Data descriptions. 

Categories and Subject Descriptors 

H. 3.5 [Information Storage and Retrieval]: Online In- 
formation Services 

General Terms 

Design, Experimentation, Standardization 

Keywords 

Web Architecture, HTTP, Linked Data, Resource Version- 
ing, Web Archiving, Temporal Applications 

I. INTRODUCTION 

The Architecture of the World Wide Web [11] states that 
dereferencing a URI yields a representation of the (current) 

state of the resource identified by that URI, and highlights 
the impracticality of keeping prior states accessible at their 
own distinct URIs: 

Resource state may evolve over time. Requiring a 
URI owner to publish a new URI for each change 
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in resource state would lead to a significant num- 
ber of broken references. For robustness, Web 
architecture promotes independence between an 
identifier and the state of the identified resource. 

Nevertheless, use cases abound that require the availabil- 
ity of (representations of) distinct prior states of resources. 
Resource versioning is of crucial importance in areas as di- 
verse as community-driven content creation, open govern- 
ment, and scientific communication. Also, as more data be- 
comes available in the Linked Data cloud, the need to version 
them will increase if only to allow efficient update of stores 
that leverage the data, and to trace their provenance. Web 
archives and content management systems possess signifi- 
cant amounts of prior versions of resources, but these prior 
versions are largely disconnected from current versions and 
discoverable only in an ad-hoc manner. Given this state of 
Web resource versioning, we consider these challenges: 

1. Given the current version of a resource, how can "fol- 
low your nose" style navigation to prior versions of the 

resource be achieved? 

2. Given any version of a resource and a particular times- 
tamp, how can "follow your nose" style navigation to- 
wards another version that matches the timestamp be 
achieved? 

This paper is concerned with versioning mechanisms that 
are machine-actionable, have global scope, and are in- 
dependent of media-type. Hence, approaches that are 
mainly beneficial to human users such as untyped hyperlinks 
in HTML with anchor text that provides navigational guid- 
ance (e.g. "previous/next version"), or version semantics 
expressed in metadatar-carrying URIs [13] are not consid- 
ered. Also, mechanisms that have version indicators specific 
to a certain server such as the deprecated "Content- Version" 
header field from RFC 2068 [6] are not considered. Similarly, 
versioning mechanisms that are specific to media-types such 
as the link element combined with the "prev" and "next" 
relationships as used in HTML [17] or Atom [15] are not 
considered. 

Our contributions are a resource versioning mechanism 
based on the global notion of time and an HTTP-based 
mechanism to navigate across versions. Furthermore, we 
demonstrate how these contributions can be applied for time 
series analysis across resource versions, and illustrate this 
using a linked data example. 



The remainder of this paper is structured as follows: Sec- 
tion 2 discusses and illustrates characteristics of resource 
versioning approaches; Section 3 provides an introduction 
to the Memento framework that extends HTTP with trans- 
parent datetime content negotiation capabilities; Section 4 
shows how the Memento framework suggests an elegant re- 
source versioning approach that is fully based on HTTP; 
Section 5 shows how the Memento versioning ideas apply to 
Linked Data; Section 6 describes the demonstrator we built 
for the DBpedia environment to illustrate how the proposed 
versioning mechanism can be used to access prior descrip- 
tions of DBpedia concepts via their existing DBpedia URIs. 
In the same section, we also show how this mechanism was 
used to conduct a time-series analysis of Gross Domestic 
Product values for several countries across DBpedia ver- 
sions. Section 7 reviews some related work, and Section 
8 holds our conclusions. 

2. RESOURCE VERSIONING 

This Section introduces core characteristics of versioning 
approaches, discusses these characteristics for a typical re- 
source versioning approach, and evaluates how that version- 
ing approach can meet the challenges (1) and (2) from the 
Introduction. 

2.1 Versioning Characteristics 

The following four core characteristics of versioning ap- 
proaches are considered: 

1. Identification: By which means are different versions 
identified? 

2. Versioning Strategy: What is the approach used to as- 
sign identifiers to versions, e.g. do new versions receive 
a new identifier, do they inherit a prior identifier, etc.? 

3. Version Relationships: How are version relationships 
between resources expressed? 

4. Version Timestamping: How is the datetime associ- 
ated with versions conveyed? 

2.2 A Typical Resource Versioning Approach 

The quote from the Architecture of the World Wide Web 
implicitly suggests a versioning approach as depicted at the 
top of Figure 1. This approach is described in terms of the 
aforementioned core characteristics: 

1. Identification: HTTP URIs are used to identify ver- 
sions of resources; each version has its own URL 

2. Versioning Strategy: A new URI is minted for each for 
each new version. When a use case requires that a re- 
source URI-Ro that started its existence at to, but at 
time ti changes state in such a way that a distinct iden- 
tity is needed, a new resource with URI-Ri is minted. 
And, if consecutively at time t2 a change in state of 
URI-Ri again requires a new identity, a resource URI- 
R2 is created (top of Figure 1). URI-Ro, URI-Ri, and 
URI-R2 co-exist and, in terms of [2] and its associ- 
ated ontology^ are time-specific resources. They rep- 
resent the evolving state of a not explicitly defined. 
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Figure 1: A resource versioning strategy, and its 
expression in RDF. 



abstract resource and are interlinked by the http: 
//www.w3 . org/2006/gen/ont#saineWorkAs property. 

3. Version Relationships: Can be made available as RDF 
metadata published about and linked from the related 
resources. The common Dublin Core Terms^ has Ver- 
sion and isVersionOf predicates (bottom of Figure 1) 
can be used. Alternatively, the machine-processable 
and media-independent HTTP Link header [14] can 
be used in combination with the registered prev and 
next relationships to express version-relationship se- 
mantics. In both cases, it should be noted that the 
semantics of the relationships do not strictly only ap- 
ply to time-based version relationships: hasVersion is 
used in cases where "a related resource is a version, edi- 
tion, or adaptation of the described resource" , whereas 
next refers to "the next resource in an ordered series 
of resources" . 

4. Version Timestamping: In case of the aforementioned 
RDF approach, additional triples can be introduced 
to express version timestamps. For example, at the 
bottom of Figure 1, the Dublin Core Terms predi- 
cates created and modified are used in accordance to 
the description for time-specific resource given in the 
aforementioned ontology as being a resource for which 
"the dates of creation and of last modification are 
the same" . It is unclear how a version timestamp 
can appropriately be expressed when using the HTTP 
Link element: conveying such information is not spec- 
ified for the prev and next relationships, the HTTP 
Last-Modified header does not provide reliable ver- 
sion semantics, and use of metadata embedded in the 
linked resource yields an approach that is dependent 
on media-type. 

The above characterization reveals the technological sub- 
strates that are used in the considered versioning approaches: 

^http : / / dublincore . org/ documents/dcmi-terms/ 



for the RDF approach, URIs, HTTP, RDF, and an appropri- 
ate RDF vocabulary; for the HTTP Link approach, URIs, 
HTTP, HTTP Link, and registered link relationships. For 
both approaches, applications such as browser plug- ins, can 
be created to support the navigation described in question 
(1) above, whereby the starting point would be the current 
resource URI-R2. Also (2) can be achieved for the RDF ap- 
proach, although a processor would need to traverse versions 
until a matching datetime is found. Lacking appropriate ver- 
sion datetime information, (2) can not reliably be achieved 
in case of the HTTP Link header. 

To summarize, both (1) and (2) can be achieved for the 
RDF approach, however: (a) Two technological substrates, 
HTTP and RDF, must be combined (b) Version datetime 
can not be used as a primary entry point; rather resource 
versions must be traversed until a version with a match- 
ing datetime is found (3) The common predicates used to 
express version relationships do not necessarily imply time- 
based version relations. 

3. THE MEMENTO FRAMEWORK 

The basic motivation for the Memento'^ work [19] is achiev- 
ing a tighter integration between the current and the past 
Web. Remnants of the past Web exist both in version-aware 
servers such as Content Management Systems (CMS, e.g. 
Wikipedia) and Version Control Systems, and in special- 
purpose Web Archives such as the Internet Archive'* and 
the on-demand WebCite^ archive. Whereas a current rep- 
resentation of a resource is available from its URI-R, prior 
representations - if they exist - are available from distinct 
resources URI-Mi (i=l..n) that encapsulate the state URI- 
R had at times ti, with ti prior to the current time. In the 
Memento framework, the resource that provides the current 
representation is named the Original Resource, whereas re- 
sources that provide prior representations are named Me- 
mentos. More formally, a Memento for a resource URI-R 
(as it existed) at time ti is a resource URI-Mi[URI-R@ti] 
for which a representation at any moment past its creation 
time tc is the same as a representation that was available 
from URI-R at time ti, with tc > ti. Implicit in this def- 
inition is the notion that, once created, a Memento always 
keeps the same representation. 

From a HTTP perspective, URI-R and URI-Mi are dis- 
connected in that HTTP provides no means to navigate to- 
wards a URI-Mi via its original URI-R. The Memento frame- 
work introduces this missing capability as follows (Figure 2): 

• Inspired by Transparent Content Negotiation for HTTP 
(conneg from now on) specified in RFC 2295 [10] that 
allows HTTP clients to negotiate with HTTP servers 
in four dimensions (media type, language, character 
set, compression). Memento introduces conneg in a 
fifth dimension: datetime. RFC 2295 introduces the 
notion of a transparently negotiable resource as the 
resource that is the target of conneg, and variant re- 
sources that vary according to the aforementioned ne- 
gotiable dimensions. Similarly, Memento introduces 
the notion of a TimeGate URI-G as a resource that 
supports conneg in the datetime dimension, and Me- 
mentos URI-Mi [URI-R@ti] as the resources that vary 

^http : / /mementoweb . org/ 
*http : / / archive . org/ 
''http : //webcitation. org/ 
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Figure 2: The Memento Framework. 



according to the datetime dimension. In a manner 
symmetrical to the way RFC 2295 introduces the Accept- 
Language request header to express the client's lan- 
guage preferences, and the Content-Language response 
header to express the language returned by the server. 
Memento introduces the Accept- Datetime and Content- 
Datetime headers to express the client's preferred date- 
time for a Memento, and the datetime of the Memento 
returned by its hosting server, respectively. It can be 
noted that, although RFC 2295 did not specify date- 
time conneg, its desirability is at least suggested by 
Tim Berners-Lee's Generic Resources Statement [2] 
as all other dimensions of genericity described in it 
(language, media-type, target-medium) are covered by 
RFC 2295. 

• In order to support discovery of a TimeGate URI-G 
for a resource URI-R, a relationship type of timegate is 
introduced for the HTTP Link response header [14] . In 
case of servers that have internal versioning/ archiving 
support (such as CMS) a TimeGate URI-G for URI-R 
can typically be exposed by the server of URI-R itself. 
In cases whereby servers rely on third parties for their 
versioning/archiving (for example by being recurrently 
crawled by the Internet Archive), URI-R and URI-G 
will reside on different servers. In addition, in order 
to allow discovering the Original Resource associated 
with a Memento, another special-purpose HTTP Link 
header, this time with a relationship type of original 
is introduced. 

• Memento also introduces the notion of a TimeBun- 
dle resource via which an overview is available of all 
Mementos that a server hosts for a given (internal or 
external) URI-R. A TimeBundle is a non-information 
resource [18] modeled as an ORE Aggregation [12] in 
which all Aggregated Resources share a temporal rela- 
tionship with the Original Resource. A TimeBundle is 
described by a TimeMap, which is a specialization of 
an ORE Resource Map. A TimeMap lists all URI-Mi 
for a given URI-R as well as their associated meta- 
data including timestamp. It also lists the Original 
Resource URI-R and its TimeGate URI-G. Appendix 
A shows an example RDF/XML TimeMap; other seri- 
alizations such as Turtle and Atom are possible. Dis- 
covery of TimeBundles is supported by the rel value 
timebundle in the HTTP Link response header. 



Throe aspects of the Memento arehitccture ensure that the 
globally deployed HTTP caching infrastructure can be lever- 
aged. First, the Original Resource URI-R and its TimeGate 
URI-G are always separate resources: URI-R is a conven- 
tional resource and URI-G is dedicated to datetime conneg. 
This eliminates caching problems that would bo caused by 
transitioning URI-R between non-negotiable and negotiable 
if URI-R and URI-G were to coincide. Second, the initial 
Memento architecture [19], required the Original Resource 
URI-R to 302 redirect to its TimeGate URI-G; as a result, 
cached versions of URI-R could not be leveraged. By using 
the timegate HTTP Link for discovery of URI-G, Memento 
clients work with caches instead of against them. Third, 
URI-G and URI-M are never the same resource so the Me- 
mentos (URI-M) can be cached as well. 

A detailed overview of HTTP request /response scenar- 
ios is available in the Memento HTTP Transactions Guide® . 
Here, we highlight certain aspects related to HTTP inter- 
actions with the TimeGate URI-G. A choice was made to 
handle cases in which URI-G is dereferenced without the 
Acccpt-Datetime header, by issuing a "302 Found" redirect 
to the most recent Memento, as opposed to offering a list 
of choices to the client. While a list would be feasible for a 
top-level resource (say, an HTML page), it would be cumber- 
some for the potentially many embedded resources (say, the 
images in the HTML page). URI-G will only return HTTP 
response code "300 Multiple Choices" if explicitly requested 
with a "Negotiate: 1.0" request header or when there are 
multiple Mementos with the same Content-Datetime^. URI- 
G will return HTTP response code "406 Not Acceptable" 
when the Accept-Datetime is outside of the datetime range 
of known Mementos. For further technical details about the 
Memento framework, we refer to the original paper [19], and 
the more recent overview of the evolved solution [20] that 
has resulted from feedback to the original ideas provided by 
both the Linked Data and Web Archiving communities. 

Since its publication. Memento has received significant 
attention. Major Web Archives have started implementing 
support*, and work is ongoing to develop support for com- 
mon CMS platforms such as Media Wiki and Drupal. Also, 
the establishment of a Memento-track at the JISC Devel- 
oper Days (Dev8D)^ organized by the UK's Joint Informal 
tion Systems Committee is an early indication of interest by 
both funders and implomonters. 

As an illustration. Figure 3 shows a Memento HTTP flow 
whereby a client requests a November 8 2009 version of the 
Wikipedia page for DJ Shadow, by interacting with its cur- 
rent URI http://en.wikipedia.org/wiki/DJ_Shadow; the 
client is pointed by http://en.wikipedia.org/wiki/DJ_Shadow 
to a TimeGate at Wikipedia; via that TimeGate the client 
successfully retrieves a Memento that meets its datetime 
preferences (only headers crucial to convey an understand- 
ing of datetime conneg are shown). We should point out 
that Wikipedia has not (yet) implemented such Memento 
HTTP flows, but a MediaWiki plug-in that adds Memento 
support is available^". 

®http : //www.mementoweb . org/guide/http/ 

''This may occur as HTTP only supports second-level time 
granularity 

®See Agenda of First Memento Implementation Meeting at 
http : / /mementoweb . org/events/I A201002/ 
''http : //wiki . 2010 . dev8d . org/w/Talk_6 
'^"Memento MediaWiki plug-in http : / / www . mediawiki . org/ 



In Figure 3, note the use of the HTTP Link header to ex- 
press the very first and most recent Mementos available from 
Wikipedia {rel= "first-memento" and rel= "last-memento" , 
respectively) as well as the Mementos that are closest in time 
{rel= "prev-memento" and rel= "next-memento") to the one 
that is returned. Note also the use of a HTTP Link header 
to point back to the Original Resource {rel= "original"). 

4. MEMENTO RESOURCE VERSIONING 

The Memento framework suggests a versioning mecha- 
nism that is fully based on HTTP (see Figure 4). These 

are its core characteristics: 

• Identification: HTTP URIs are used to identify ver- 
sions of resources. 

• Versioning Strategy: The top of Figure 4 shows URI-R 
as the resource from which at any point in time the cur- 
rent representation is served, and URI-Mi as resources 
that provide access to representations that wore previ- 
ously available from URI-R. In terms of [2] and its as- 
sociated ontology^^, URI-R is a time-generic resource, 
whereas all URI-Mj are time-specific resources. This 
strategy is different than the one shown in Figure 1, yet 
aligned with the stable URI principle of Cool URIs [3, 
18]: instead of minting a new URI for every new ver- 
sion, keep the URI stable and mint new URIs for old 
versions. This approach has become rather widespread; 
for example, http : // cnn . com and http : //en . wikipedia . 
org/wiki/DJ_Shadow are such URI-R, whereas http: 
//web . archive . org/web/2001091 1203610/http : //www . 
cnn. com and http: //en. wikipedia. org/w/ index .php? 
title=DJ_Shadow&oldid=337446696 are examples of 
respective URI-M,. 

• Version Relationships: A timegate HTTP Link header 
provided in response to GET/HEAD requests issued 
against the stable URI-R points at a TimeGate. And, 
an original HTTP Link header provided in response 
to GET/HEAD requests issued at Mementos URI-Mi 
points at URI-R of the Original Resource. As de- 
scribed, a TimeGate supports datetime conneg based 
on the content of the Accept-Datetime header. It is 
a time-travel resource that acts as a gateway between 
the time-generic URI-R and its associated time-specific 
Mementos URI-Mi . The result of the datetime conneg 
is a Memento that meets the expressed datetime pref- 
erence. Also, the prev-memento and next-memento re- 
lationships may be used in the HTTP Link header to 
point at Mementos that are adjacent in time to the 
returned one. 

• Version Timestamping: Versioning of URI-R is not 
required as it always is the current version. Mementos 
URI-Mi arc timcstampcd by means of the Content- 

Datetime response header. 

The technology substrate used by the Memento versioning 
approach is fully centered on HTTP: URI, HTTP, HTTP 
Link with to-be-registered link relationships, HTTP date- 
time conneg. The challenges formulated in the Introduction 
can be addressed as follows (bottom of Figure 4): 

wiki/Extension : Memento 

^^http : //www . w3 . org/2006/gen/ont 



HEAD http://en.wlkipedia.org/wikl/DJ_Shadow HTTP/1.1 
Accept-Datetlme: Sun, 08 Nov 2009 00:00:00 GMT 

HTTP/1.1 200 OK 

Link : <http : //en . wikipedia .org/ Special : TimeGate/http : //en . wikipedia . org/wiki/D J_Shadow> 
; rel="timegate" 

GET http: //en. wikipedia .org /Special : TimeGate/http: //en. wikipedia. org/ wiki/DJ_S hadow 
HTTP/1 . 1 

Accept-Datetlme: Sun, 08 Nov 2009 00:00:00 GMT 

HTTP/1.1 302 Found 
TCN: choice 

Vary: negotiate, Accept-Datetime 

Location: http : //en . wikipedia . org/w/ index . php?title=DJ_ShadowSoldid=32417 804 
Link : <http : //en . wikipedia . org/wiki/DJ_Shadow>; rel-" original" 
Alternates : 

{ "http : / /en . wikipedia .org/w/ index . php? title=D J_ShadowSoldid=14 93 68 8 " 0.01 

{type text/html} (language en} (dt "Sun, 28 Sep 2003 01:42:00 GMT" first}}, 
{ "http : //en .wikipedia. org/w/index.php?title=DJ_ShadowSoldid=337 44 66 96" 0.01 

{type text/html} {language en} {dt "Tue, 12 Jan 2010 19:55:00 GMT" last}}, 
{ "http : //en .wikipedia.org/w/index.php?title=DJ_ShadowSoldid=32 417 8 40" 1 . 

{type text/html} {language en} {dt Thu, 05 Nov 2009 23:41:00 GMT}}, 
{ "http: //en. wikipedia. org/w/ index. php?title=DJ_ShadowSoldid=32 258 60 71" . 8 

{type text/html} {language en} {dt "Wed, 28 Oct 2009 14:307:00 GMT" prev} } , 
{ "http : //en .wikipedia. org/w/index.php?title=DJ_ShadowSoldid=32 51 642 83" . 7 

{type text/html} {language en} {dt "Thu, 26 Nov 2009 23:50:00 GMT" next}} 

GET http: //en. wikipedia. org/w/index.php?title=DJ_ShadowSoldid=32 417 8 040 
Accept-Datetime: Sun, 08 Nov 2009 00:00:00 GMT 

HTTP/1.1 200 OK 

Content-Datetime: Thu, 05 Nov 2009 23:41:00 GMT 

Link : <http : //en . wikipedia . org/wiki/DJ_Shadow>; rel="original" 

Alternates : ... 



Figure 3: Memento HTTP Request/Response Cycle. 
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Figure 4: Memento Resource Versioning. 



expressed in the timegate HTTP Link header returned 
by URI-R. The TimeGate supports datetime conneg 
allowing the client to obtain various versions (Memen- 
tos) by varying the content of its Accept-Datetime re- 
quest header. In addition, in cases where the prev- 
memento and next-memento relationships are avail- 
able in the Alternates header provided in TimeGate re- 
sponses, a client can engage in version-to- version nav- 
igation with a certainty that the version-relationships 
are time-based. 

Given any version of a resource and a particular times- 
tamp, how can "follow your nose" style navigation to- 
wards another version that matches the timestamp be 
achieved? A version URI-Mi provides an original HTTP 
Link header pointing at the stable URLR. From thereon, 
this scenario is the same as described in the previ- 
ous point; the timestamp is used as the content of 
the Accept-Datetime request header. The Content- 
Datetime provides the earliest datetime at which the 
returned version became available; that version was 
still the then-current one at the datetime that was ex- 
pressed in the Accept-Datetime header. 



1. Given the current version of a resource, how can "fol- 
low your nose" style navigation to prior versions of 
the resource be achieved? The current version is the 
stable URLR. A client application can follow its nose 
to a TimeGate for URLR by using the URI that is 



5. MEMENTO RESOURCE VERSIONING 
AND LINKED DATA 

Figure 5 shows how Memento integrates in the Linked 
Data environment. In this case, URI-R is a cool URI for a 
non-information resource [18], and the current description 
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Figure 5: Memento Resource Versioning and Linked 
Data. 



Table 1: DBpedia Demonstrator Database Table. 



id 


subject 


start 


end 


triples 


integer, 
autojncrement , 
not null, 
PK 


varchar(256) 


datetime 


datetime 


blob 



of URI-R is available at URI-S. A TimeGate URI-G is in- 
troduced for URI-R, and to support its discovery a timegate 
HTTP Link header is provided in responses to GET/HEAD 
requests to URI-R. When a Linked Data client is in need 
of prior descriptions of URI-R, it follows its nose to URI-G, 
where it can use datetime conneg to arrive at a description 
of URI-R as it existed at some time in the past. Note that 
the conneg with URI-G can include dimensions other than 
datetime. The media-type dimension that is commonly used 
in Linked Data to allow a choice of descriptions expressed in 
RDF serializations or HTML can also be supported. Simi- 
larly, negotiation on language can be supported. 

6. THE DBPEDIA DEMONSTRATOR 
6.1 Demonstrator Set-Up 

We have implemented the architecture depicted in Figure 
5 in the DBpedia context. We first downloaded the five prior 
English-language versions of DBpedia (2.0 through 3.3)^^ 
in NT format. Using a python script, the approximately 
600 Million triples were loaded into a MySQL table (Table 
1). Loading took approximately 15 hours, and resulted in a 
MylSAM table of 81 GB. 

For each DBpedia subject URI-R, we exposed a TimeGate 
to support content negotiation in the datetime and media- 
type dimensions. For example, our TimeGate for DBpedia's 
France resource http://dbpedia.org/resource/France is 
http : / /mementoarchive . lanl . gov/dbpedia/timegate/http : 
//dbpedia.org/resource/Frcmce. The datetime function- 
ality was implemented by retrieving all distinct start/end 

^^http : //wiki . dbpedia. org/Downloads34 



combinations for the requested subject URI-R. This ap- 
proach readily supports providing the first-memento, last- 
memento, next-memento and prev-memento relationships in 
the HTTP Link header provided in responses. The returned 
Memento is the one with the start/end interval that cov- 
ers the datetime requested via conneg. For conneg requests 
with a datetime value that is in the range of the current 
DBpedia version, the TimeGate issues an HTTP 302 redi- 
rect to the Original Resource URI-R at dbpedia.org. Me- 
mentos are available both in HTML and RDF/XML. For 
example, the Memento for DBpedia 3.3's France resource 
in HTML is http://mementoarchive.lanl.gov/dbpedia/ 
memento/20090701/http: //dbpedia. org/page/France. 

Colleagues at DBpedia kindly implemented the timegate 
HTTP Link header pointing at our TimeGates. This re- 
quired approximately one hour and consisted of adding a 
stored procedure in the OpenLink Virtuoso engine to add 
the appropriate HTTP Link header. 

Figure 6 shows a Memento HTTP flow whereby a client 
requests the description of France that was available from 
DBpedia on March 20, 2008. Only headers crucial to convey 
an understanding of the conneg are shown. 

To illustrate full Memento compliance, we also imple- 
mented TimeBundle/TimeGate support for our DBpedia 
version archive. This functionality was not used to achieve 
the time-series analysis described below. The Appendix 
shows our TimeMap for the DBpedia resource http : / /dbpedia . 
org/resource/France; the content should be self-explanatory. 

Although DBpedia currently operates under a regime of 
recurrent discreet updates, both the proposed Memento ap- 
proach and our specific database design support a possible 
future regime in which DBpedia is updated on an ongoing 
basis. In this case, an archiving mechanism would need to 
be added to ensure that versions of distinct DBpedia de- 
scriptions are pushed/pulled into the version archive as they 
change. 

6.2 Time-Series Analysis using Memento Re- 
source Versioning 

To illustrate the power of the proposed approach, we im- 
plemented a simple time-series analysis using both past and 
current DBpedia data. We set out to trace the evolution over 
time of the Gross Domestic Product Per Capita for various 
countries, leveraging the http://dbpedia.org/property/ 
gdpPppPerCapita property. 

The straightforward data-time-traveling algorithm used to 
construct the time-series data-set is described by the below 
pseudo code. It must be noted that the actual script must 
rely on some ad-hoc heuristics to deal with diverging data 
formats used for GDP values. 



resources := [list of country description TimeGate URIs] 
times ;= [list of date times, one per version including current] 
prop := "http; //dbpedia. org/property/gdpPppPerCapita" 
values := {> 

foreach r in resources: 

values [r] : = [] 

foreach t in times: 

data := fetchCURI-TG/r, Accept -Datetime : t, Accept: 
"application/rdf +xml" ) 



graph 
value 
value 



parse (data) 

graph. sparql (SELECT val WHERE { r prop ?val . }) 
normalize (value) 



values [r] .push(value) 



HEAD http://dbpedla.org/resource/Paris HTTP/1.1 
Accept: appllcation/rdf +xml 

Accept-Datetlme: Thu, 20 Mar 2008 18:00:00 GMT 
HTTP/1.1 200 OK 

Link : <http : //mementoarchive . lanl . gov/dbpedia/timegate/http : //dbpedia . org/re source/ France> 
; rel="timegate" 

GET http : / /mementoarchive . lanl . gov/dbpedia/timegate/http : //dbpedia . org/ resource /France HTTP/1 . 1 
Accept: application/rdf +xml 

Accept-Datetime: Thu, 20 Mar 2008 18:00:00 GMT 

HTTP/1.1 302 Found 
TCN: choice 

Vary: negotiate, accept, accept-datetime 

Location : http : //mementoarchive . lanl . gov/dbpedia/200 8 0201/http : //dbpedia .org/resource /France 
Link: <http://dbpedia.org/resource/France>; rel-"original" , 
<http : //mementoarchive . lanl . gov/ dbpedia /memento/2007 901/http : //dbpedia . org/data/France>; 

datetime="Sat, 01 Sep 2007 00:00:00 GMT"; rel="f irst-memento" , 
<http : //mementoarchive . lanl . gov/dbpedia/memento/2 00 91101/http : //dbpedia . org/data/France>; 

datetime="Sun, 01 Nov 2009 00:00:00 GMT"; rel="last-memento" , 
<http : //mementoarchive . lanl . gov/ dbpedia /memento/2007 901/http : //dbpedia . org/data/France ; 

datetime="Sat, 01 Sep 2007 00:00:00 GMT"; rel="prev-memento" , 
<http : //mementoarchive . lanl . gov/dbpedia/memento/200 0801/http : //dbpedia . org/data/France>; 

datetime="Fri, 01 Aug 2008 00:00:00 GMT"; rel="next-memento" , 
<http : //mementoarchive . lanl . gov/ dbpedia /timebundle/ http : / /dbpedia . org/ resource /France>; 

rel="tlmebundle" 

GET http: //mementoarchive . lanl .gov/dbpedia/2008 0201/http : //dbpedia . org/ resource/ France HTTP/1 . 1 
Accept: application/rdf +xml 

Accept-Datetime: Thu, 20 Mar 2008 18:00:00 GMT 
HTTP/1.1 200 OK 

Content-Datetime: Fri, 01 Feb 2008 00:00:00 GMT 
Content-Type : application : rdf +xml 

Link: <http ; //dbpedia . org/resource/France>; rel="origlnal" , 
<http : //mementoarchive . lanl . gov/ dbpedia /memento/2007 901/http : //dbpedia . org/data/France>; 
datetirae="Sat, 01 Sep 2007 00:00:00 GMT"; rel="f irst-memento" , ... 



Figure 6: Memento DBpedia HTTP Request /Response Cycle. 



The collected data were then turned into a chart (Figure 
7) using the Google Chart API". 

7. RELATED WORK 

Little research has explored a protocol-based solution to 
augment the Web with time travel capabilities. TTApache 
[5] introduced an ad-hoc RPC-style mechanism to access 
archived representations given the URI of their original, e.g. 
"page.html?02-Nov-2009" . This approach reveals the local 
scope of the problem addressed by TTApache, as opposed 
to the global perspective taken by the Memento datetime 
conneg framework. Indeed, the query components are is- 
sued against a specific server, and are not maintained when 
a client moves to another server as is the case with the 
Accept-Datetime header of datetime conneg. TTApache 
also allowed addressing archived representations using ver- 
sion numbers in query components rather than datetimes. 
This capability is similar to the deprecated "Content- Version" 
header field from RFC 2068 [6] and other, similar expired 
proposals (e.g., [16]). Such versioning features have not 
found wide-spread adoption, presumably because their ad- 
dress space is tied to a specific resource or server, and not 
universal like datetime. TTApache also provided support for 
reserved terms as query components such as "page.html?now" 

^■^http : / / code . google . com/apis/charttools/ index . html 



This capability is similar to link relationship types such as 
"latest- version" , "predecessor- version" , "successor- version" , 
and "working-copy-of" proposed in [4] to allow simple ver- 
sion navigation between Web resources. The focus of this 
proposal that emerged from the AtomPub [7] context, how- 
ever, is clearly on editorial version control (cf. WebDav, 
Java Content Repository). Also, it provides no means to 
navigate versions based on datetime information. 

There is a relationship between the described work and 
efforts that research the problem of provenance of Linked 
Data, specifically those provenance aspects concerned with 
the time intervals in which specific data is valid. For ex- 
ample, [8], is concerned with provenance graphs that allow 
expressing such validity information, whereas [9] focuses on 
applications to support preserving link integrity over time. 
Our proposal introduces a native HTTP approach that al- 
lows leveraging the results of these efforts at Web scale. 

8. CONCLUSIONS 

URIs like http://weather.exainple.com/oaxaca used in 
[11] have gained significant functionality in the Linked Data 
context as they start providing access not only to HTML in- 
tended for human consumption, but also to data expressed 
in some RDF serialization intended for machine processing. 
When publishing data in accordance to Memento's HTTP- 
based versioning mechanism proposed in this paper, their 
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Figure 7: A time-series analysis conducted across DBpedia versions using Memento's HTTP-based versioning 
approach. 



value further increases as they become entry points to both 
current and past versions of data. The time-series analysis 
described in Section 6.2 is an admittedly simple demonstra- 
tion of a subtle and powerful change in the utility of Linked 
Data URIs. 

The URI http : // weather . example . com/ oaxaca can now 

be leveraged to obtain an overview of Oaxaca's weather in 
the past months, merely by issuing HTTP GET requests 
with varying datetime preferences. Similarly, time-traveling 
a Dow Jones data URI can result in an overview of the 
stock market's evolution at any desired granularity. Trac- 
ing the evolving state of traffic congestions, implemented in 
Zoetrope [1] by high-frequency crawls and scraping of a traf- 
fic web site could be achieved by dereferencing a single data 
URI with varying timestamps instead. 

While this paper has focused on Linked Data, it should 
be clear that the proposed versioning mechanism can be ap- 
plied to Web resources in general. It could, for example, be 
leveraged to facilitate navigating across issues of Web-based 
newspapers and magazines, and it can play an important 
role in better integrating the data-intensive eScience and 
eHumanities efforts into the Web. Hence, the addition of a 
time dimension to the Web is not something only digital ar- 
chaeologists should care about. It is an enabler for a global 
HTTP-based versioning mechanism that can support a new 
range of temporal applications for both the document and 
the data Web. This paper has merely scratched the surface 
of a new world of possibilities. 
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APPENDIX 

A. AN RDF/XML TIMEMAP 

The following is an RDF/XML TimeMap for http:// 
dbpedia. org/resource/France. 

<?xml versioii="1.0" eiicoding="utf-8"?> 
<rdf :RDF 

xmlns : f oaf =' http : //xmlns . com/f oaf /O . 1/ ' 

xmlns : dcterms= ' http : / /purl . org/dc/terms/ * 

xmlns :mGm= 'http ; //www.mementoweb . org/terms/tb/ ' 

xmlns : dc= ' http : //purl . org/dc/elements/1 . 1/ ' 

xmlns : rdf = ' http : //www . w3 . org/1999/02/22-rdf -syntax-ns# ' 

xmlns : ore= * http : //www . openarchives . org/ore/ terms/ ' 

xmlns : rdf sl= 'http : //www . w3 . org/2001/Ol/rdf -schema# ' > 
<ore :ResourceMap rdf : about =" http : //mementoar chive . lanl . gov/dbpedia/timemap/rdf /http: //dbpedia. org/resource/France "> 
<rdf : type rdf :resource="http : / /www.mementoweb . org/terms/tb/TimeMap"/> 
<dcterms:modif ied>2010-02-17T05:26;27Z</dcterms:modif ied> 
<dcterms : created>2010-02-17T05 : 26 : 27Z</dcterms : created> 
<dc : f ormat>application/rdf +xml</dc ; f ormat> 
<dcterms : creator> 

<rdf : Description rdf : about="http : //f oresite-toolkit . googlecode . com/#pythonAgent "> 

<f oaf :mbox>f oresiteSgooglegroups . com</f oaf :mbox> 

<f oaf :name>Foresite Toolkit (Python) </f oaf :name> 

</rdf :Description> 

</ dcterms : creator> 

<ore : describes> 

<ore : Aggregation rdf ; about="http : //mementoar chive . lanl . gov/dbpedia/timebundle/http : //dbpedia. org/resource/France "> 
<ore : aggregates rdf :resource="http: //mementoar chive . lanl . gov/dbpedia/memento/20070901/http ; / /dbpedia . org/dat a/France "/> 
<ore ; aggregates rdf :resource="http: //mementoar chive . lanl . gov/dbpedia/memento/20080201/http: //dbpedia. org/dat a/France "/> 
<ore : aggregates rdf : resource="http : / /mementoar chive . lanl . gov/ dbpedia/memento/20080801/http : // dbpedia . org/data/France " /> 
<ore : aggregates rdf :resource="http: //mementoar chive . lanl . gov/dbpedia/memento/20081101/http: //dbpedia. org/data/France "/> 
<ore : aggregates rdf :resource="http : //mementoarchive . lanl . gov/dbpedia/memento/20090701/http: //dbpedia. org/data/France "/> 
<ore : aggregates rdf :resource="http : //mementoarchive . lanl . gov/dbpedia/timegate/http: //dbpedia. org/resource/France" /> 
<ore : aggregates rdf : resource="http : //dbpedia. org/resource/France "/> 
<dc : title>Memento Time Bundle for http : //dbpedia. org/resource/France</dc : title> 
<rdf ; type rdf ; resource="http : //www .mementoweb. org/terms/tb/TimeBundle"/> 
</ore : Aggregation> 
</ore : describes> 
</ore : Resour ceMap> 



<rdf : Description rdf :about="http : / /www. openar chives . org/ore/terms/Aggregation"> 
<rdf si ; label>Aggregation</rdf si : label> 

<rdf si : isDef InedBy rdf : resource="http : //www. openar chives . org/ore/terms/"/> 
</rdf :Description> 

<rdf : Description rdf :about="http : //www. openarchives . org/ore/terms/ResourceMap"> 
<rdf Si :label>ResoiirceMap</rdf si : label> 

<rdf si : isDef inedBy rdf :resource="http: //www. openarchives . org/ore/terms/"/> 
</rdf :Description> 

<mem : TimeGate rdf : about="http : //mement oar chive . lanl . gov/dbpedia/timegate/http : //dbpedia . org/re source /France "> 

<mem: timeGateFor rdf :resource="http: //dbpedia. org/resource/France"/> 

<mem; covers rdf :nodeID="gtKXRtug21"/> 
</meni : TimeGate> 
<mem:Period rdf :nodGlD="gtKXRtug21"> 

<mem:end rdf :datatype="http: //www. w3 . org/2001/XMLSchema#dateTime">2009-ll-01T00 : 00 : 00+00 : 00</mem; end> 

<mem: start rdf :datat3rpe="http : //www. w3.org/2001/XMLSchema#dateTime">2007-09-01T00: 00: 00+00 :00</mem:start> 
</mem : Per iod> 

<meiii: Memento rdf :about="http: //mementoarchive . lanl .gov/dbpedia/meiiiento/20070901/http: //dbpedia. org/ data/France" > 
<iiiem : validOver> 
<mem:Period> 

<mem : start rdf : datatype="http : //www. w3 . org/2001/XMLSchema#dateTime">2007-09-01T00 : GO : 00+00 : 00</mem : start> 
<mem : end rdf ; dat atype= "http : //www . w3 . org/200 l/XMLSchema#dateTime " >2008-02-01T00 : 00 : 00+00 : 00</mem : end> 
</mem: Period> 
</mem : validOver> 

<mein:mementoFor rdf :reso'urce="http : //dbpedia. org/resource/France"/> 
< / mem : Mement o > 

<mem : Memento rdf : about="http : //mementoarchive . lanl . gov/dbpedia/memento/20080201/http : / /dbpedia . org/ data/France" > 
<mem : validOver> 

<mem:Period> 

<mem: start rdf : datatype="http : //www . w3 . org/2001/XMLSchema#dateTime">2008-02-01T00 : GO : OG+00 : GO</mem: start> 
<mem : end rdf : datatype="http : //www . w3 . org/2001/XMLSchema#dateTime">2008-08-01T00 : 00 : 00+00 : 00</mem : end> 
</mem : Period> 
</mem : validOver> 

<mem:mementoFor rdf :reso'urce="http : //dbpedia. org/resource/Fraiice"/> 
< / mem : Mement o > 

<mem: Memento rdf :about="http: //mementoarchive . lanl .gov/dbpedia/memento/20080801/http: //dbpedia. org/ data/France" > 
<mem:validOver rdf :nodeID="gtKXRtug42"/> 

<mem: mement oFor rdf :resource="http: //dbpedia. org/resource/France"/> 

</mem : Memento> 

<mem : Period rdf : nodeID="gtKXRtug42 " > 

<mem : end rdf : datatype="http : //www . w3 . org/2G01/XMLSchema#dateTime" >2008-08-01T00 : OG : 00+00 : OG</mem : end> 
<mem : start rdf : datatype="http : //www . w3 . org/2001/XMLSchema#dateTime" >2009-ll-01T00 : 00 : 00+00 : 00</mem : start> 

</mem:Period> 

<mem: Memento rdf :about="http: //mementoarchive . lanl .gov/dbpedia/memento/20081101/http: //dbpedia. org/ data/France" > 
<mem : val idO ver rdf : node ID= " gt KXRtug49 " /> 
<mem : mementoFor> 

<mem: OriginalResource rdf : about="http: //dbpedia. org/resource/France"/> 
</mem:mementoFor> 
</mem:Memento> 

<mem : Period rdf : nodeID="gtKXRtug49 " > 

<mem:end rdf :datatype="http: //www. w3 . org/2G01/XMLSchema#dateTime">2008-ll-01T00 : 00 : 00+00 : 00</mem: end> 
<mem : start rdf : datatype="http : //www. w3 . org/2001/XMLSchema#dateTime">2009-07-01T00 : 00 : 00+00 : 00</mem: start> 

</mem:Period> 

<mem: Memento rdf : about = "http : //mementoarchive . lanl . gov/dbpedia/memento/20090701/http : //dbpedia. org/ data/France" > 
<mem:validOver rdf :nodeID="gtKXRtug56"/> 

<mem: mement oFor rdf :resource="http: //dbpedia. org/resource/France"/> 

</mem : Memento> 

<mem : Period rdf : nodeID= "gtKXRtug56 " > 

<mem : end rdf : datatype="http : //www . w3 . org/2001/XMLSchema#dateTime " >2009-07-01T00 : 00 : 00+00 : 00</mem : end> 
<mem: start rdf :datatype="http : //www. w3.org/2001/XMLSchema#dateTime">2009-ll-01T00: 00: 00+00 :00</mem:start> 
</mem:Period> 
</rdf :RDF> 



